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The accompanying disk contains an RT-11 Operating System along with all of tlie source 
(BCPL and MACROll), binary, load, and command files required for the operation and 
maintenance of the Ethernet software. 

The PDP-11 Ethernet software is composed of the following Alto packages; 

EFTP Protocol & Program 

PUP Levels 1 & 0 

Context 

Queue 

Alloc 

Timer 

All Alto BCPL code was syntactically modified to conform to the requirements and 
limitations of the PDP-11 DOS compiler, but is otherwise unchanged. All assembly 
language code was rewritten in MACROll. Because the code is virtually unchanged from 
the Alto implementation, the Alto documentation is totally definitive and trustworthy; 
however because of a PDP-11 BCPL limitation, defaulted arguments must be set' to zero 
(rather than omitted). The documentation for the assembly language interface to BCPL 
routines is attached to this letter along with a definition of the NDB which has been 
changed for compatibility with the Ethernet hardware. All files of the form *.PAL are 
MACROll code which was generated by the BCPL compiler running under the DOS 
Operating System, and all files of the form *.MAC were hand coded in MACROll. 

All code is independent of the operating system except for EFTP Program and a routine 
called OSA.MAC. EFTP Program uses monitor functions (contained in RT11.MAC) to 
read/write the operator’s console and the system disk. OSA.MAC sets up the stacks, 
initializes the timer, and allocates memory for the use of the Alloc package; it also contains 
routines which were a part of the Alto Operating System (MoveBlock, Zero, Noop, 
SetBlock, CallSwat, SysErr, Use, GetFixed, and FixedLeft). 


Greg Thomas 
/aim 
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Basic System Notes 
Store Allocation 


The code of compiled BCPL programs and libraries 
resides in high store, immediately above the BCPL global 
vector. The POP system stack, which is only allocated 
enough space to perform monitor tasks, is below the global 
vector and below the system stack is the BCPL runtime stack, 
which runs down store. 


HI store 


LO store 


code 


global s 
SP 


BCPL 

stack 


DOS 




1 inker 
output 

I 

^ I 


<- top of DOS buffers 


<- top of resident DOS 


The DEC DOS monitor lives at the bottom of store and 
acquires transient space from the store immediately above 
itself. The BCPL I/O library also obtains space for stream 
buffers from this area, which is administered dynamically by 
DOS. . 


2 . 


Register Allocation 


The BCPL stack register is general register zero, 
the system stack register (the SP) and the program counter 
(the PC) are necesarily registers six and seven. v 

On function entry registers one to four are used to 
pass the first four arguments, on function return register 
one holds any result. The only use of the system stack by 
the BCPL system is on function entry to hold temporarily the 
return link. 


BCPL Stack Arrangement 


3. 
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As noted the runtime stack grows down store, and is 
allocated as shown. 


HI store 


LO store 


stack ptr 

I 


.-I-- 

III old frame | | | current frame 

-T-t- 


debug j 

I 

previous 

routine 

link 


I I 

debug| 

I 

current 

routine 

link 


The 'savespace-size' holding the static links of 
function entry is of size two, one of which is used for the 
code address linking, and hence also the previous frame 
size, and the other for debugging information or for use 
with the Intcode Interpreter. 

Vectors are arranged to run up store, according to 
the BCPL definition. However the "vector" of arguments to a 
routine does not follow the definition - it grows down store! 


4. Global Vector Linking 


The Global Vector is known at link time as the Named 
Csect ’GLOBAL’, linking of BCPL programs with this Csect is 
automatic. At the machine code level the conventional 
mechanism of accessing this Csect is by assigning a variable 
G to the address of global zero and offsetting from this 
address. Thus:- 


.CSECT GLOBAL 
G=. 


;enter Csect Global 

;G = address of global zero 


.=6+101 .+101. ,*at global one hundred and one 
FUNC ;insert the value FUNC 


The variable 6 must only be assigned to once per assembler 
segment. 


5. Function calling Sequence 


JSR 


PC,§G+N ;calling through global N/2 

M ‘.frame size M+2 bytes 


6. Function Entry Sequence 
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SUB @0{SP),RO 

MOV (SP)+,-(R0) 

MOV R0,R5 

MOV R1,-(R5) 

MOV R2,-(R5) 


7. Function Exit Sequence 


MOV (R0)+.R5 
ADD (R5)+,R0 
JMP (R5) 


;standard entry code 
:end of entry sequence 
;copy known args to the stack 
;first arg on 

;second on, etc up to four args 
;code of the routine 


;code of the routine 
jresult, if any, must be in R1 
;return completed 


8. Code for Debugging Aids 


On function entry the address of the called routine 
can be saved on the runtime stack in the link; the eptry 
code then becomes, 

.BYTE 7 , 'A' 

.BYTE 

.BYTE ’D’,’E' 

.BYTE ’F’,’G’ 

SUB eO(SP),RO 

MOV PC.(R0) 

MOV (SP)+,-(R0) 

. ; etc 

Profile counting is performed by the sequence 


;a BCPL string which is 
;the name of the function. 

;the string, if present, is 
;always of length seven chars. 
;as normal 

;save the PC on the stack 
;as normal 


INC {PC)+ 
0 


:add one to the current count 
;the current count 


Further facilities are under development, (e.g. 
trace routines) 


9. BCPL Addresses 


At all times it must be remembered that BCPL' 
manipulates addresses as integers. These integers are the 
addresses of consecutive sixteen bit fields in store and 
hence must be word addresses. To convert a BCPL address to a 
machine address one must thus convert to a byte address, 
which is most easily performed by a single left shift. 
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10. BCPL Strings 


BCPL strings are vectors, considered as a sequence 
of bytes, the less significant half of each word preceeding 
the more significant, and these pairs being treated in their 
order of appearance in the vector. The value of the first 
byte of the string is the number of bytes in the string, 
excluding itself. 


May 1974 
SRL 




Data Structures 

Queue Structures 

The Ethernet Software makes extensive use of queues. PBI’s exist on any of three 
queues: an input queue (pbilQ), an output queue (oQX and a free queue (pbiFreeQ). 
There is also a queue of Network Data Block’s (NDB); these exist on ndbQ. At the present 
time the only NDB is for the Ethernet (EtherNDB). Another queue in the system is the 
packet filter queue (pfQ); it is a queue of the names of programs which are to be used in 
determining the validity of received packets. The queue heads for oQ and pfQ are located 
within an NDB. The structure of a queue is a follows: 

Queue Head 

head pointer to first item in queue (0 if empty) 

tail pointer to last item in queue (0 if empty) 

Queue Item 

link pointer to next item in queue (0 if last item) 

EtherNDB Structure 

c 

The EtherNDB contains all the information necessary for the operation of the Ethernet 
and its hardware: 


EtherNDB 

link 

localNet 
local Host 

netType/deviceNum 
numGPBI 
pfQ: head 
tail 

pupPF: link 
predicate 
queue 

encapsulatePup 
levelOTransmit 
levelOStats 
iCommand: count 
address 
status 

iPBI 

oCommand: count 
address 
status 
delay 

load 

xmtTimeout 
oPBI 
oQ: head 
tail 


pointer to next NDB 

focal net number • zero if unknown 

local host number 

type of network/address of hardware 
PBI’s allowed to gateway for this net 
queue of packet filters - first item 

- last item 

PUP packet filter • pointer to next filter 

• address of EtherPupFilter 

• address of pbilQ 
address of EncapsulateEtherPup 
address of SendEtherPacket 
address of SendEtherStats (reserved) 

2’s comp of input word count 

input buffer location 
input control & status word 
input PBI being processed 
2’s comp of output word count 
output buffer location 
output control & status word 
random number for output delay 
load mask for random countdown 
transmitter timeout 
output PBI being processed 
output queue -first item 

• last item 



PBI Structure 

A PBI is a buffer that contains a PUP and information pertaining to it. 


PBI 

link 

queue 

socket 

ndb 

status 

timer 

packetLength 

dest/src 

type 

length 

transport/type 

«cJ(1) 

id(2) 

dPort: net/host 
socket(l) 
socket(2) 
sPort: net/host 
socket(l) 
socket(2) 
words 


pointer to next PBI 
address of xmitted-PBI queue 
address of owning socket 
address of NDB for this PBI 
PBI control info 
retransmission timer 
no. of words in packet 
dest host / src host 
packet type 

length of PUP (bytes) \ 

PUP control / PUP type 

sequence no. (1) 

sequence no. (2) 

dest net / host 

dest socket id (1) 

dest socket id{2). 

src net / host 

src socket id(1) 

src socket id(2) 

data words in PUP / 


PUP 


Context Structure 

A context exists on a context queue and is used by the context package to control the 
execution of tasks on a round-robin basis. The context contains a stack pointer, some 
space reserved for the user, and a stack (which contains a resume execution address). 


Context 

link 

sp 

exspac 

stack 


pointer to next Context 
current stack pointer 
space reserved for user 
stack used by task 





